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ETSI 



ETSI TS 101 315 V4.1.1 (2003-11) 



Scope 



The present document specifies how the service capabiHties as defined in TS 101 878 [1] can be used to synthesize 
examples of TIPHON simple call, call diversion on busy and call completion on no reply. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ETSI TS 101 878 (V4.1.1): "Telecommunications and Internet Protocol Harmonization Over 

Networks (TIPHON) Release 4; Service Capability Definition; Service Capabihties for TIPHON 
Release 4". 

[2] ETSI TS 101 314 (V4.1.1): "Telecommunications and Internet Protocol Harmonization Over 

Networks (TIPHON) Release 4; Abstract Architecture and Reference Points Definition; Network 
Architecture and Reference Points". 

[3] ETSI TS 101 882-1: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 4; Protocol Framework Definition; Part 1 : Meta-protocol design rules, 
development method, and mapping guideline". 

[4] ETSI TS 101 315 (VI. 1.1): "Telecommunications and Internet Protocol Harmonization Over 

Networks (TIPHON) Release 3; Functional entities, information flow and reference point 
definitions; Guidelines for application of TIPHON functional architecture to inter-domain 
services". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

bearer: logical association of functional entities in an IP telephony application and transport network which creates an 
end to end media flow for no longer than the duration of a call 

domain: collection of physical or functional entities within an administrative domain which share a consistent set of 
policies and common technologies 

Domain Identifier (DID): globally unique identifier of a domain 

NOTE: Domain identifiers may be mapped to the IP Telephony Administrative Domain (ITAD) Numbers, 
registered by lANA and used by the TRIP Protocol. 

end-user: entity using the services of an IP telephony service provider or transport network operator 

end-user domain: collection of physical or functional entities under the control of an end-user which share a consistent 
set of policies and common technologies 
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functional entity: entity in a system that performs a specific set of functions 

Functional Group (FG): collection of functional entities within a domain 

NOTE: In TIPHON systems functional groups are used to structure the necessary functionality to offer IP 
telephony services across domains. 

gateway functional group: functional group containing the functionality of a network functional group also the 
functionality necessary to connect calls to the SCN 

NOTE: Gateway functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

home network functional group: functional group, which is aware of the service application subscribed to by the 
end-user 

NOTE: Home network functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

intermediate (transit) network functional group: functional group connecting the serving network functional group 
to the home network functional group 

NOTE: The intermediate network functional grouping is only present when the serving network functional 
grouping and the home network functional grouping are not directly connected. 

information flow: interaction between a communicating pair of functional entities 

interconnection function: functional entity connecting two networks having differing administrative policy such as 
Quality of Service (QoS) or addressing policy but employing the same signalling protocol, and transport technology, at 
the point of interconnect 

interface: shared boundary between two communicating systems, devices or equipment 

IP network: packet transport network comprising one or more transport domains each employing the IP protocol 

IP telephony: any telephony related service that is supported on a managed IP network 

IP telephony service provider: service provider who offers IP telephony services 

NOTE: The same business entity may act as both a transport network operator and an IP telephony service 
provider. 

network functional group: functional group containing the functionality required to establish a call between two 
terminals, a gateway and a terminal, or two gateways 

NOTE: network functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

packet flow/transport flow: stream of packets of the same type identified by common address and port numbers 

NOTE: The stream may contain either signalling information or content description together with media 
information. 

protocol: set of semantics, syntax and procedures, which govern the exchange of information across an interface 

reference point: conceptual point at the conjunction of two communicating functional entities 

service domain: collection of physical or functional entities offering IP telephony services under the control of an IP 
telephony service provider which share a consistent set of policies and common technologies 

serving network functional group: functional group that enables terminal functional groups to connect to an IP 
telephony service provide 
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Switched Circuit Network (SCN): telecommunications network, e.g. Public Switched Telephone Network (PSTN), 
Integrated Services Digital Network (ISDN), and General System for Mobile communications (GSM), that uses 
circuit-switched technologies for the support of voice calls 

NOTE: The SCN may be a public network or a private network. 

terminal: endpoint within the user equipment on which signalling and media flows originate and/or terminate 

terminal functional group: functional group representing all the IP telephony functionality within an end-user's 
terminal 

NOTE: Terminal functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

ticket: obtained through the registration session, when used in a call it provides the terminal/user with a means to show 
a valid registration exists 

transport domain: collection of transport resources sharing a common set of policies, QoS mechanisms and transport 
technologies under the control of a transport network operator 

transport function: functional entity representing the collection of transport resources within a transport domain which 
are capable of control by a transport resource manager 

transport network: collection of transport resources, which provide IP transport functionality 

transport network operator: business entity operating a transport network 

transport policy entity: functional entity that maintains the policies of a transport domain 

Transport Resource Manager (TRM): functional entity that applies a set of policies and mechanisms to a set of 
transport resources to ensure that those resources are allocated such that they are sufficient to enable transport flows 
with QoS guarantees across the domain of control of the TRM 

user equipment: equipment under the control of an end-user 

user profile: service specific information about a user of a service application 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AC Access Control 

AP Application Plane 

BC Bearer Control 

CC Call Control 

CCNR Call Completion on No Reply 

CFB Call Forwarding on Busy 

DID Domain IDentifier 

GSM General System for Mobile communications 

lANA Internet Assigned Numbers Authority 

ICE Interconnect Function 

IP Internet Protocol 

ISDN Integrated Service Digital Network 

IT AD IP Telephony Administrative Domain 

LI Lawful Interception 

MC Media Control 

NGN Next Generation Networks 

PSTN Public Switched Telephony Network 

QoS Quality of Service 

QoSM Quality of Service Management 

QoSP Quality of Service Policy 

SC Service Control 

SCN Switched Circuit Network 

SpoA Service point of Attachment 
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SREG 

TRIP 

TRM 



Service network REGistration function 
Telephony Routing over IP Protocol 
Transport Resource Manager 



4 Introduction 

The TIPHON project does not specify standards for services (including supplementary services) but rather standardizes 
a set of root capabilities termed service capabilities. The purpose of the present document is to link the use of service 
capabilities as building blocks to the more familiar language of services. 

The development picture used in TIPHON is shown in figure 1 . The area shaded in yellow identifies those areas which 
are subject to standardization, i.e. for which TSs, ESs, and ENs will be developed. The present document shows by 
example how a small set of services is built from the suite of service capabilities with a view to show that the set of 
service capabilities is sufficient to allow service providers to build their services. 



Desired Services 



S 



Service Capabilities 




Requirements 



Protocols 



Architecture 



i 



Implementation 



Service Deployment 



Figure 1 : Standardization map of TIPIHGN 



Solutions offered by TIPHON 



5.1 



Introduction 



The service capabilities of TIPHON defined in TS 101 878 [1] offer the capability to build a large number of services. 
Existing services may be emulated using the service capabilities, and new services may be synthesized from them. The 
following clauses offer some examples of the form of services that may be offered using TIPHON. 



5.2 Access Control (AC) 



Access Control (AC) is the ability of a service provider to control the traffic utilizing its communications resources. 
This ability was inherent in the Circuit Switched Networks, where the access to network resources could be restricted 
by the local switch. The access control may be applied for example, to ensure only authorized (e.g. paying) users have 
access to communications resources, to restrict the number of sessions to avoid congestion etc. Therefore, Access 
Control remains an important capability that should be supported in IP environment also. 
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TIPHON has developed an access control capability for IP environment based on its Registration and transport plane 
capabilities. The registration framework ensures that only authorized users have access to the requested services. Once 
authorized for a service, e.g. telephony, a user is provided with an authorization token which enables the user access to 
communications services. The access to transport resources is provided with the authorization of the application plane. 
The transport plane has functions called Transport Resource Manager (TRM), and Interconnect Function (ICF) that play 
an important role in supporting access control, amongst many other services. ICF acts as a controllable firewall and 
allows traffic to flow through once it has been authorized by the Application Plane (AP). Unauthorized traffic is 
blocked. 



5.3 Protocol interworking 



There are several standardized protocols available that can be implemented on one or more reference points of the 
TIPHON architecture defined in TS 101 314 [2], e.g. The "C" reference point can be implemented using BICC, SIP, 
H.323, or ISUP. The choice of protocol for a reference point is implementation specific. TIPHON recognizes that 
different service providers may support one or more of the above protocols in their networks, and require interworking 
between different protocols. TIPHON addresses this issue via the TIPHON meta-protocol (TS 101 882-1 [3]) and 
protocol profiles. The protocol profiles are based on the context and behaviour of meta-protocol, which can act as an 
interworking function, leading to automatic interworking between different protocols such as H.323 and SIP as shown 
in figure 2. 



SIP, H.323, BICC, ISUP, V.52 

< ► 



TIPHON Meta-protocol 
Interworking Function 



SIP, H.323, BICC, ISUP, V.52 
M ► 



Protocol Interworking 

Figure 2: Protocol Interworking via TIPHON meta-protocol 

Another direct advantage of using the meta-protocol as an interworking function is that it ensures the service 
interworking between similar services implemented using different protocols, provided the TIPHON service capabilities 
support such services. 



5.4 



Mobility 



TIPHON supports user mobility via its registration framework (TS 101 882-1 [3]). The user mobility enables a user to 
register from different locations and terminals. This allows the user to access the communications services from 
different locations. This includes access to unique or standardized services offered by the Home service provider. 

There are two scenarios of mobility covered by TIPHON: 

• User at home. 

• Roaming user scenario. 

The first scenario allows a user to receive services from its Home service provider inside its home domain. This 
includes accessing services from different points of attachment. 

The second scenario allows a user to receive services while roaming in another administrative domain. This includes the 
provision for services provided by the visited domain, as well as Home domain. The execution of services from Home 
domain is particularly important in the case of unique services that only the Home service provider provides, and does 
not share the service logic with the visited domain. 
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5.5 Lawful Interception (LI) 



Lawful Interception (LI) is an ability to intercept voice communications origination from or terminating to a party, on 
the request of the law enforcement agencies. Lawful Interception is a regulatory requirement and must be supported 
irrespective of the underlying technology for communications. TIPHON has developed capabilities in Application and 
Transport planes (TS 101 315 [4]) to support this service. TIPHON achieves lawful interception via its Interconnect 
Function, ICF, which allows multiple call legs to be set up between the NWFG serving the party to be intercepted, and 
the law enforcement agency. This service is illustrated in TS 101 315 [4]. 

VoIP interconnection allows a service provider domain to connect to another service provider domain, and terminate 
calls originating from one domain to another. TIPHON has developed capabilities in the application and Transport 
planes to handover calls from one domain to another in a secure and QoS enabled manner. This service is illustrated in 
TS 101 882-1 [3]. If the interconnecting domains deploy different call control protocols, the interworking can also be 
achieved via the Meta-protocol Interworking function, as explained in clause 5.3. Privacy of IP addresses of parties in 
communications on different domains is also achieved via ICF. 



6 Creation of services from service capabilities 

The flexibility of the approach taken in TIPHON to define service capabilities rather than standardized services means 
that there may be many ways to construct the same potential service. The presentation of services in the present 
document are therefore examples that demonstrate the use of service capabilities and which do not emulate precisely the 
ISDN basic call or ISDN supplementary services. 



6.1 



Method overview 



6.1 .1 TIPHON Service capabilities 



TS 101 878 [1] describes the set of service capabilities required for the realization of services for TIPHON Release 4. 
These service capabilities are shown in class notation in figure 3. 



Call 




Bearer 




Profile 


- call : Call Descriptor 

- cdr : CallDataRecord 


- bearer : BearerDescriptor 


-profile : RegistrationProflle 










«sc» + optimiseO 




«sc» + register() 




«sc» + setupO 




«sc» + createO 




«sc» + attacfiO 


«sc» + cleardownO 




«sc» + deleteO 




«sc» + dereglsterO 


«sc» + redirectO 




«sc» + modifyO 




«sc» + detachO 


«sc» + joln() 




«sc» + joln() 




«sc»+ authentlcateO 


«sc» + IdentltyDeliveryO 




«sc» + setConditlonO 




«sc» + authoriseO 


«sc» + setPriorityO 




«sc» + ClearConditlonO 




«sc» + transfer() 


«sc» + interrogateO 




«return» + condition Return() 




«sc» + setStatusO 


«sc» + locatlonDeliveryO 




«return» + create_Return() 




«sc» + getStatusO 
«sc»+ setCondltlonO 


«sc» + setConditionO 




«sc» + clearConditlonO 




«sc»+ ClearConditlonO 


«sc» + routeO 




«retum» + register_Return() 


«return» + condition ReturnQ 




«retum» + attacfi_ReturnO 


«return» + setup_Fletum() 




«retum» + status_ReturnO 
«retum» +transfer_Return() 
«retum» + condftionReturnO 
«retum» + authorlse_ReturnO 














Message 




Media 






«sc» + createO 


- media : MedlaDescriptor 






- transport : Transport 




«sc» + retrie\«() 
«sc» + deleteO 








«sc» + clearMedlaEncodeO 




«sc» + setStatusO 




«sc» + createTransportO 




«sc» + getStatusO 




«sc» + clearTransportO 




«return» + message ReportQ 




«sc» + setMedlaEncodeO 




«return» + message ResponseO 




«return» + setlVledia_Return() 




«return» + message ReturnQ 




«return» + createTransport_Return() 




«return» + message_Status( 









Figure 3: Overall UML class model for TIPHON (NGN) service capabilities 
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6.2 Example of the simple call service 

The following example shows how service capabilities may be used to construct a typical service e.g. simple call. 

6.2.1 Operation invocation sequence for the example Call 

Figure 4 shows the example simple call service involving originating and terminating networks. It is important to note 
that this example shows how a non-standardized application may use TIPHON standardized service capabilities to 
synthesize an example simple call service. Figure 4 conforms to the UML conventions for an operation invocation 
sequence diagram. 



:NGN 

U ser 



Originating 
Application 



1 request to setup i 



16 ALERTING 



:Call 



call to 'calledParty ' 

2 authorise (regid, servic ;) 



3 authorise_Return (ticket) 



4 setup (calledParty, call 



7 create (bearer) 



8^ Create_Return (bearer 



9 setM ediaEncode (med 



10 setM edia_Return (m 1; ndle) 



1 1 createTransport: 



1 2 createTransport_Ret 



19 setup_Return (callld 



:Profile 



:B earer 



ngParty, call) 
5 route (cal 



edParty, callir 



setup (called 



r 1 ( tHandle) 




:M edia 



gParty , call) 



arty, callingP 



18 ANSW ER 



arty, call) 



go Speech path established 



21 HANG UP 



22 cleardown (callld) 



23 delete (bearerld) 



*v 



24 clearM ediaEncoder ( nHandle) 



2 5 clearT ran sport (tHan lie) 



V 



2 



Terminating 
Application 



:NGN 
U ser 



13 I/C CALL 



14 ALERTING 



17 ANSWER 



NOTE: The usual call progress indications e.g. alerting, busy, connect, are contained within setup. 
Figure 4: Example operation invocation sequence for the call 
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Table 1 describes the class object invocations for the example call. The parameters that are supplied to and returned by 
each operation are identified. 

Table 1 : Explanation of operation invocation sequences for an example call 



# 


Operation 


class 


Parameters 


Comments 


1 








The TIPHQN User 
requests a call to a given 
called party 


2 


Authorize 


Profile 


user identity, service capability 
to be authorized 




3 


Authorize Return 


Profile 


authorization ticket 




4 


Setup 


Call 


calling user identifier, called 
user identifier, call identity, call 
type, service provider 
preference, QoS service class 




5 


Route 


Call 


calling user identifier, called 
user identifier, service provider 
preference, QoS service class, 
next network name 




6 


Setup 


Call 


calling user identifier, called 
user identifier, call identity, call 
type, service provider 
preference, QoS service class 


Next instance of setup 


7 


create 


Bearer 


bearer characteristics 




8 


create Return 


Bearer 


bearer identifier 




9 


setlVlediaEncode 


Media 


media type, media attributes, 
transport characteristics 




10 


SetMedia Return 


Media 


media identifier 




11 


createTransport 


Media 


transport descriptor 




12 


createTransport Return 


Media 


transport identifier 




13 








Terminating application 
informs called party 
terminal of an incoming call 


14 








Called party terminal 
informs the terminating 
application that the called 
user is being alerted 


15 








The terminating application 
informs the originating 
application that the called 
user is being alerted 


16 








The originating application 
informs the calling party 
that the called user is being 
alerted 


17 








The called party answers 
the call and informs the 
terminating application 


18 








The terminating application 
informs the originating call 
class that the called user 
has answered 


19 


setup Return 


Call 


call identifier 




20 








The speech path is 
established 


21 








The calling party hangs up 


22 


Cleardown 


Call 


call identifier 




23 


Delete 


Bearer 


bearer identifier 




24 


ClearlVlediaEncode 


Media 


media identifier 




25 


ciearlransport 


Media 


transport identifier 
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6.3 Example call forwarding on busy service 

The following clauses provide examples showing how service capabilities may be used to construct typical services. 

6.3.1 Operation invocation sequence for CFB service activation 

The following example given in figure 5 shows how service capabilities may be used to construct a typical CFB service 
including activation and deactivation. It is important to note that this example shows how a non-standardized 
application may use TIPHON standardized service capabilities to synthesize an example service activation. Figure 5 
conforms to the UML conventions for an operation invocation sequence diagram. 



:Profile 



Terminating 
Application 



1 U; er activates Call Diversi )n on Busy service 



2 setcondition (on busy, redirect (redirect_to_Party)) 



3 setcondition_Return (handle) 



:NGN 
User#l 



Figure 5: Example operation invocation sequence for CFB activation 
Table 2: Explanation of the operation invocations 



# 


Operation 


class 


Parameters 


Comments 


1 








The TIPHON User 
activates the Call Diversion 
on Busy service 


2 


SetCondition 


Profile 


condition, redirect process, 
directed to address 




3 


SetCondition Return 


Profile 


condition identifier 





6.3.2 Operation invocation sequence for CFB service 

The following example describes how a Call Forwarding on Busy (CFB) service could be synthesized using TIPHON 
service capabilities. The preconditions for the CFB service are that both the calling and called users are registered, the 
called user has activated the CFB service and is active in a call. 

Figure 6 shows the operation invocation sequence. It is important to note that this example shows how a 
non-standardized application may use TIPHON standardized service capabilities to synthesize an example CFB service. 
Figure 6 conforms to the UML conventions for an operation invocation sequence diagram. 
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:TIPHON 

User 



Originating 
Application 



1 request to setup ; 
► 



3 authorise_Return (tickejt) 

H 



17 ALERTING 



:Call 



call to 'callcdParty' 

2 authorise (regid, servici 



4 setup {callcdParty, cal 

► 



8 create (bearer) 



^ Create_Return (bearer 



10 setMcdiaEncode (me li i) 



11 setMedia_Return (mH 



12 creatcTransport: (trai s 



1 3 createTransport_Reti r i ( tHandle) 



:Profile 



ngParty, call) 



20 setup Return (callld) 

H ■■" 



edParty, callir 



setup (calledP 



redirect (direc 



ndle) 



22 HANG UP 



23 cleardown (callld) 



24 delete (bearerld) 



*1] 



25 clearMediaEncoder ( nHandle) 



26 clearTransport (tHandle) 



:Bearer 



arty, callingP 



tedToParty, c: 



16 ALERTING 



Speech p 



-ni 



:Media 



gParty, eall 



ath establ 



■ni 



ished 



Terminating 
Application 



:TIPHON 

User 



14 I/C CALL 



, 15 ALERTING 



18 ANSWER 



:TIPHON 

User 



NOTE: The usual call progress indications e.g. alerting, busy, connect, are contained within setup. 
Figure 6: Example operation invocation sequence for CFB establishment 
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Table 3: Explanation of the operation invocations 



# 


Operation 


class 


Parameters 


Comments 


1 








The TIPHQN User 
requests a call to a given 
called party 


2 


Authorize 


Profile 


user identity, service capability 
to be authorized 




3 


authorize Return 


Profile 


authorization ticket 




4 


setup 


Call 


calling user identifier, called 
user identifier, call identity, call 
type, service provider 
preference, QoS service class 




5 


route 


Call 


calling user identifier, called 
user identifier, service provider 
preference, QoS service class, 
next network name 




6 


setup 


Call 


calling user identifier, called 
user identifier, call identity, call 
type, service provider 
preference, QoS service class 


Next instance of setup 


7 


redirect 


Call 


Call identifier, redirect to party 
identifier 




8 


create 


Bearer 


bearer characteristics 




9 


create Return 


Bearer 


bearer identifier 




10 


setlVlediaEncode 


Media 


media type, media attributes, 
transport characteristics 




11 


setlVledia Return 


IVIedia 


media identifier 




12 


createTransport 


IVIedia 


transport descriptor 




13 


createTransport Return 


IVIedia 


transport identifier 




14 








Terminating application 
informs called party 
terminal of an incoming call 


15 








Called party terminal 
informs the terminating 
application that the called 
user is being alerted 


16 








The terminating application 
informs the originating 
application that the called 
user is being alerted 


17 








The originating application 
informs the calling party 
that the called user is being 
alerted 


18 








The called party answers 
the call and informs the 
terminating application 


19 








The terminating application 
informs the originating call 
class that the called user 
has answered 


20 


setup Return 


Call 


call identifier 




21 








The speech path is 
established 


22 








The calling party hangs up 


23 


cleardown 


Call 


call identifier 




24 


delete 


Bearer 


bearer identifier 




25 


ClearlVlediaEncode 


IVIedia 


media identifier 




26 


clearTransport 


IVIedia 


transport identifier 
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6.3.3 Operation invocation sequence for CFB service deactivation 

Figure 7 shows an example of deactivation of the CFB service. It is important to note that this example shows how a 
non-standardized application may use TIPHON standardized service capabilities to synthesize an example service. 
Figure 7 conforms to the UML conventions for an operation invocation sequence diagram. 



:ProfiIe 



2 clearcondition (handle) 



Terminating 
Application 



1 U; 



er deactivates Call Dive sion on Busy service 



:TIPHON 

User 



Figure 7: Example operation invocation sequence for CFB deactivation 
Table 4: Explanation of the operation invocations 



# 


Operation 


class 


Parameters 


Comments 


1 








The TIPHON User 
deactivates the Call 
Diversion on Busy service 


2 


ClearCondition 


Profile 


condition identifier 





6.4 Example Call Completion on No Reply (CCNR) service 
6.4.1 Operation invocation sequence for the CCNR service 

Figure 8 shows the operation invocation sequence for an example TIPHON Call Completion on No Reply service. The 
precondition needed for the CCNR service is that both the calling and called users are registered and authenticated. 

The following example describes how a CCNR service could be synthesized using TIPHON service capabilities. The 
preconditions for the CCNR service are that both the calling and called users are registered and the calling user 
subscribes to the CCNR service. It is important to note that this example shows how a non-standardized application may 
use TIPHON standardized service capabilities to synthesize an example CFB service. Figure 8 conforms to the UML 
conventions for an operation invocation sequence diagram. 
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:TIPHO 

User 


Originating 
Application 



1 request to setup 

— »t 



16 ALERTING 



17 Invoke CCNR 
► 



20 HANG UP 



28 CCNR call 



29 ACCEPT CCNR 
► 



:Call 



a call to called party 
2 authorise (regld, servic 



3 authorise_Return (tickt t) 



4 setup (calledParty, cal 



7 create (bearer) 



8 create_Return (bearer 



9 setMediaEncode (mec 



10 selMedia_Return (m -^a 



11 createTransport: (tra 



1 2 createTransport_Ret 



1 8 setCondition (go 



1 9 condition_Return 



2 1 cleardown (call 



:Profile 



ngParty, call 
5 route (cal edParty, calli igParty, call 



22 delete (bHandle) 



23 clearMediaEncode 



(mHandle) 



24 clearTransport (tH; 



27 notify (condition-'t n_hook;')) 



30 clearCondition (hant le) 

► 



31 setup (calledParty, callingParty 



( tHandle) 



)n look, notify( 



nditionHanc le) 




6 setup (c 



lledParty, callingParty, ca 



■^ 



otify (conditic 



n-'on_hook') i 



■^ 



32 Call setup continues 
I I 



Terminating 
Application 



:TIPHON 
User 



13 I/C CALL 



14 ALERTING 



25 GO ON HOO 




Figure 8: Example operation invocation sequence for CCNR establishment 
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Table 5: Explanation of the operation invocations 



# 


Operation 


class 


Parameters 


Comments 


1 








The TIPHQN User requests a call to a 
given called party 


2 


authorize 


Profile 


user identity, service capability 
to be authorized 




3 


authorize Return 


Profile 


authorization ticket 




4 


Setup 


Call 


calling user identifier, called 
user identifier, call identity, call 
type, service provider 
preference, QoS service class 




5 


route 


Call 


calling user identifier, called 
user identifier, service provider 
preference, QoS service class, 
next network name 




6 


setup 


Call 


calling user identifier, called 
user identifier, call identity, call 
type, service provider 
preference, QoS service class 


Next instance of setup 


7 


create 


Bearer 


bearer characteristics 




8 


create Return 


Bearer 


bearer identifier 




9 


setlVJediaEncode 


Media 


media type, media attributes, 
transport characteristics 




10 


setlVledia Return 


Media 


media identifier 




11 


createTransport 


Media 


transport descriptor 




12 


createTransport Return 


Media 


transport identifier 




13 








Terminating application informs called 
party terminal of an incoming call 


14 








Called party terminal informs the 
terminating application that the called 
user is being alerted 


15 








The terminating application informs the 
originating application that the called 
user is being alerted 


16 








The originating application informs the 
calling party that the called user is 
being alerted 


17 








The calling party invokes the CCNR 
service 


18 


SetCondition 


call 


condition, redirect process 




19 


condition Return 


call 


condition identifier 




20 








The calling party hangs up 


21 


cleardown 


call 


call identifier 




22 


delete 


bearer 


bearer identifier 




23 


clearlVlediaEncode 


media 


media identifier 




24 


clearTransport 


media 


transport identifier 




25 








The intended called party goes on hook 


26 


status 


call 


condition identifier 


Event "go on hook" triggers callback 


27 








The call class reports the condition to 
the originating application 


28 








The originating application notifies the 
terminal of the CCNR call 


29 








The calling party goes on hook and 
accepts the CCNR call 


30 


ClearCondition 


call 


condition identifier 




31 


Setup 


Call 


calling user identifier, called 
user identifier, call identity, call 
type, service provider 
preference, QoS service class 




32 








Normal call setup continues 
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